大型语言模型（LLM）应用架构
A16z 在这周发布了一篇专注于大型语言模型（LLM）应用架构的文章：https://a16z.com/2023/06/20/emerging-architectures-for-llm-applications/
这篇文章详细解析了创业公司和大公司在设计和实现LLM应用时常用的系统、工具和设计模式。作为一名非技术背景的读者，我尝试从中理解这些应用背后的架构设计思路：
上图主要基于“in-context learning”设计模式。
那么，首先我们需要理解什么是“in-context learning”。可以参考维基百科上的相关条目：https://en.wikipedia.org/wiki/In-context_learning_(natural_language_processing)
在语言模型训练中，In-context learning（情境学习） 主要描述了模型如何基于给定的文本上下文预测或产生后续的文本内容。也就是说，模型会利用前文的信息来产生相关且适当的响应。这种方式模仿的是人类的对话习惯：我们总是基于对话的上下文来构思并决定我们接下来要说什么。
例如，假设我问，“今天天气如何？”你可能会根据你所处的地点和时间来回答，比如“今天阳光明媚”或者“今天下雨了”。这就是在利用上下文（当前的天气状况）来响应我的问题。
所以，“In-context learning”在这个上下文中指的是语言模型基于给定的对话上下文生成合适回应的能力。
使用大型语言模型（LLM）主要有三种方式：
从头开始训练自己的模型 基于开源模型进行微调（fine-tuning） 直接使用API
其中，情境学习（in-context learning）主要适用于第三种方式。尽管相比自己从头开始训练模型和微调模型来说，直接使用API更为简便，但由于API调用费用会随着提示（prompt）长度的增长而指数级增加，因此如何更高效地利用情境学习的方法也变得非常关键。你可以参考a16z的另一篇文章来深入了解：https://a16z.com/2023/05/25/ai-canon/
这篇文章将整个工作流程分解为三个主要步骤：
数据预处理/嵌入：在这个阶段，需要处理和存储私有数据（以法律文档为例），以便后续能够进行检索。这通常涉及将文档分割成小块，通过Embedding嵌入模型进行处理，然后将处理后的数据存储在一种称为向量数据库的特殊数据库中。我在之前的文章中详细讲解过这个部分：LangChain 读 pdf（上） 提示构建/检索：当用户提交了一个查询（例如，一个法律问题）时，应用程序会构建一系列提示，用于提交给语言模型进行处理。一个完整的提示通常包含由开发者编写的提示模板、有效的输出样例（比如 few-shot）、必要的从外部APIs获取的信息（比如【AIGC 学习】获取电影信息 - LangChain 使用5），以及从向量数据库检索得到的相关文档。 提示执行/推断：提示编译完成后，它们将被提交给一个预训练的LLM（大型语言模型）进行处理，这包括使用专有的模型API和开源或自我训练的模型。一些开发者可能还会在这个阶段添加操作性系统，如日志记录、缓存和验证等功能。我在之前的文章中没有涉及到这个部分，之后可以写一篇专门介绍这方面的内容。
我们来分别详细解析这三个步骤：
数据预处理/嵌入
上下文数据（Contextual data） 可能包含各种格式的文档，如PDF、CSV或SQL等结构化数据。处理和转化这些数据的方式有很多，一些人倾向于使用如Databricks或Airflow这样的ETL（提取、转换、加载）工具，而一些人则倾向于使用编排框架，如LangChain和LlamaIndex。
嵌入（Embeddings） 是一种方法，它能将高维、离散或无序的数据（如单词、句子、用户、商品等）转换为低维、连续、有序的向量。许多开发者会选择直接使用OpenAI API，如text-embedding-ada-002模型。一些大公司可能选择使用Cohere，而倾向于开源的开发者则可能会选择使用Hugging Face的Sentence Transformers库。https://huggingface.co/sentence-transformers
向量数据库（Vector database） 是专门用来存储和处理向量数据的数据库。它能有效地存储嵌入向量（Embeddings），并支持对这些嵌入进行高效查询。许多人选择使用Pinecone，还有一些开源的选择，如Weaviate、Vespa和Qdrant，以及本地向量管理库Chroma和Faiss，还有增强的OLTP系统，如pgvector。
在深度学习和自然语言处理领域，上下文窗口（context window） 通常指在生成预测时模型可以参考的输入数据的数量或范围。例如，在处理文本数据时，上下文窗口可能指的是当前单词周围的单词数量。对于语言模型来说，更大的上下文窗口意味着模型可以考虑更多的历史信息来生成预测。
有关数据预处理和嵌入，有人认为随着大型模型可用上下文窗口的增大，Embeddings嵌入可能会更多地融入到提示中。但专家们的观点则相反，他们认为随着上下文窗口的扩大，计算成本也会随之增加，而使用Embeddings嵌入可以提高效率。
提示构建/检索
我们可以通过零样本（zero-shot）和少样本（few-shot）的提示与LLM进行交互。这方面的内容我在一个笔记中有所说明，参考ChatGPT prompt 书写指南 🧭。除此之外，还有更高级的提示工程技术，如思维链（CoT，Chain-of-Thought）和思维树（ToT，Tree of Thoughts）等，具体可参考https://www.promptingguide.ai/techniques。我也会在稍后为大家详细解析这些技术。这些技术可以用于构建聊天机器人（ChatBot）、进行基于文档的问答等。
在上一步骤中，我们提到了LangChain和LlamaIndex这两种编排框架，它们在这个步骤可以发挥重要作用。它们抽象化了许多与提示链相关的细节；界定了与外部API的接口（包括确定何时需要API调用）；从向量数据库中检索上下文数据；以及在多个LLM调用中保持内存的维护。它们还为许多常见应用提供了模板。它们的输出是一个或一系列的提示，这些提示将提交给语言模型。我曾在过去的文章中对LangChain做过一些扫盲，未来也会有更详细的分享【AIGC 学习】LangChain 使用1。
提示执行/推断
目前，OpenAI在LLM领域处于领先地位。通常，人们会以gpt-4或者gpt-4-32k模型为起点构建LLM应用。然而，当产品进入扩展阶段时，他们通常会转向使用gpt-3.5-turbo模型，尽管其准确率较低，但价格只有gpt-4的五十分之一，且运行速度更快。Anthropic的Claude也提供了API，其上下文窗口可以达到100k。有些开发者会选择使用开源模型，一些云服务如Databricks、Anyscale、Mosaic、Modal和RunPod可能会提供相应的预设工具和服务。Hugging Face和Replicate也为运行AI应用提供了简单的API和前端交互界面。
与OpenAI这些专有模型相比，LLM的开源模型目前仍存在差距，但这个差距正在逐渐缩小。比如Meta的LLaMa，以及Together、Mosaic、Falcon和Mistral等。当然，Meta也正在准备开源LLaMa2。
操作工具（operational tools） 通常指那些用于监控、管理、优化或调试模型运行的工具，这些工具在当前的开发者中并未广泛使用。以下一些类型的工具都可以被视为"操作工具"：
日志和跟踪工具，例如Weights、Biases、MLflow、PromptLayer和Helicone，可以记录模型的输出、输入和运行状态，帮助开发者理解模型的行为。 性能分析工具，例如Guardrails和Rebuff，可以评估模型的运行速度和资源使用情况，帮助开发者优化模型的性能。 缓存工具，例如Redis，可以存储模型的输出结果，以便在需要时快速获取，从而提高应用程序的响应速度和成本效益。 安全工具，可以检测和防止模型的滥用或攻击，保护模型的安全和稳定性。
LLM应用的非模型部分通常托管在云端，例如Vercel。此外，还有两种新的托管方式正在出现：Steamship为开发者提供端到端托管服务，包括LangChain、多租户数据上下文、异步任务、向量存储以及密钥管理；另一种方向是，像Anyscale和Modal这样的公司允许开发者在同一地方托管模型和Python代码。
AI代理框架
文章中提到，所给的参考架构中最关键的遗漏部分是AI代理框架。文章提及了AutoGPT，我之前也有分享过 - 【AIGC 学习】Auto-GPT 使用 - ChatGPT API 使用2。而没有提到的AI代理还有HuggingGPT、Reflexio等，其中HuggingGPT我之前也做过介绍 - HuggingGPT，未来有机会我会给大家演示一下Reflexio。然而，现阶段大多数的AI代理框架仍处于概念验证阶段——虽然可以展示出令人震惊的效果，但尚未能可靠且可复制地完成任务。我将会密切关注他们在未来的发展。
目前，AI在行业中的应用主要有两种方式：AI Productivity，即提升现有生产效率，以及AI Native，即创造过去无法实现的产品。无论是哪一种应用，AI都赋予了个别开发者能力，使他们在短短几天内就能构建出令人惊叹的效果，超越了那些需要由大团队花费数月才能构建的监督式机器学习项目。a16z的这个框架可以帮助我们更好地利用这个强大的工具。